…in for access to the Go Plugin Filter Metrics

Description

Adding support in the Helm chart to allow an Opt-In feature for users to configure a new port to open in the adminService. This new port will allow users to set Values.adminService.goPluginMetricsPort=8878 to expose port 8878 for users to get access to the Go Filter Plugin Metrics, which we added in Edge Stack release 3.11.0. This allows users to expose an additional port so that they may use metric scraping tools to scrape the new Go Plugin metrics using Helm.

Related Issues

List related issues.

Testing

Running helm install --dry-run --debug <LOCAL-CHART> has the expected default output, where goPluginMetricsPort inside the adminService file is empty, the adminService remains unchanged, and emissary-ingress installs with no changes.

Running helm install --dry-run --debug <LOCAL-CHART> --set adminService.goPluginMetricsPort=8878 has the expected output where the goPluginMetricsPort field inside the adminService has the value 8878, the environment variable ENABLE_PLUGIN_FILTER_METRICS is set to "true", port 8878 is opened on the emissary-ingress deployment, and the adminService has the port 8878 exposed on it.

Checklist

• Does my change need to be backported to a previous release?

  • What backport versions were discussed with the Maintainers in the Issue?

• I made sure to update CHANGELOG.md.

  Remember, the CHANGELOG needs to mention:

  • Any new features
  • Any changes to our included version of Envoy
  • Any non-backward-compatible changes
  • Any deprecations

• This is unlikely to impact how Ambassador performs at scale.

  Remember, things that might have an impact at scale include:

  • Any significant changes in memory use that might require adjusting the memory limits
  • Any significant changes in CPU use that might require adjusting the CPU limits
  • Anything that might change how many replicas users should use
  • Changes that impact data-plane latency/scalability

• My change is adequately tested.

  Remember when considering testing:

  • Your change needs to be specifically covered by tests.
    • Tests need to cover all the states where your change is relevant: for example, if you add a behavior that can be enabled or disabled, you'll need tests that cover the enabled case and tests that cover the disabled case. It's not sufficient just to test with the behavior enabled.
  • You also need to make sure that the entire area being changed has adequate test coverage.
    • If existing tests don't actually cover the entire area being changed, add tests.
    • This applies even for aspects of the area that you're not changing – check the test coverage, and improve it if needed!
  • We should lean on the bulk of code being covered by unit tests, but...
  • ... an end-to-end test should cover the integration points

• I updated DEVELOPING.md with any any special dev tricks I had to use to work on this code efficiently.

• The changes in this PR have been reviewed for security concerns and adherence to security best practices.